Here for tomcat & jboss logging you mean the logging on those application servers that rely on JUL ?

Yes, they rely on it as a framework, but provide their own implementations, for Loggers but also for the actual Handlers, for example - org.apache.juli.FileHandler

[minor] because the publish method is defined on Handler class, maybe we could have a common method matcher.

I didn't because it will add yet another level to the inheritance hierarchy, making it three-level hierarchy for three instrumentations. I figured it's too much

[minor] is there any reason not to rely on co.elastic.apm.agent.sdk.weakconcurrent.WeakConcurrent#buildThreadLocal here ? Also, it might be worth checking if we need to have those fields within an @GlobalState.

co.elastic.apm.agent.sdk.weakconcurrent.WeakConcurrent#buildThreadLocal here ?

There is no need because the value in both cases is basic Java and the this instrumentation is using the bootstrap CL. It is in my todo list to add an asciidoc regarding ThreadLocal and when to use which, it just doesn't get to the top of priorities still...

Also, it might be worth checking if we need to have those fields within an @globalstate

This plugin instruments basic Java types loaded by the bootstrap CL. Why should we require it to be a @GlobalState?

[question] here we get the "first file" from the implementation internal state, how do we know that it's representative of all the files that the FileHandler might be writing to ?

If you look at java.util.logging.FileHandler#openFiles, you'll see that all files are created based on a single pattern. We only use this for the enclosing log directory. If the user makes the pattern so that directories get changed between logs, that is unexpected and we will just use the first dir. I don't think we need to add special handling for such case, but we can improve based on feedback.